home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / hp48_2 / fpgdir < prev    next >
Internet Message Format  |  1995-03-31  |  6KB
  1. From comp.sys.handhelds Sun Jun  9 13:41:11 1991
  2. Path: seq!ecsgate!mcnc!uvaarpa!haven.umd.edu!udel!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpcvra.cv.hp.com!rnews!hpcvbbs!akcs.joehorn
  3. From: akcs.joehorn@hpcvbbs.UUCP (Joseph K. Horn)
  4. Newsgroups: comp.sys.handhelds
  5. Subject: Re: HP 48 Faster PGDIR
  6. Message-ID: <2850bd41:3374.4comp.sys.handhelds;1@hpcvbbs.UUCP>
  7. Date: 8 Jun 91 11:40:08 GMT
  8. References: <284dca48:3374comp.sys.handhelds@hpcvbbs.UUCP> <25590171@hpcvra.cv.
  9. Lines: 42
  10.  
  11. Bill Wickes writes that running my FPGDIR after recalling objects from
  12. the target directory to the stack can cause problems.
  13.  
  14. Wow!  That's for sure!  I just tried it, and the very first attempt
  15. tanked everything in the machine.
  16.  
  17. Rats.  The moral here is twofold:
  18.  
  19. (1) The obvious: don't use FPGDIR unless you KNOW FOR SURE that there are
  20. no references to objects that will be left floating in limbo.
  21.  
  22. (2) Less obvious: Be Careful When You Hide Objects In Directories!  Many
  23. articles and programs about "hiding" things have floated down this
  24. bitstream, and not once did anybody mention that hiding things in
  25. directories can send the 48 out to lunch.  But if ALL the items in a
  26. directory are hidden, it's an accident waiting to happen.  Because then
  27. simply PURGEing the directory (if there are any memory references to its
  28. contents) will cause problems at the next garbage collection.
  29.  
  30. The first moral is worded with "unless" because the situation is exactly
  31. the same for the new 256K and 512K bankswitched cards now available for
  32. the 48.  I just played with a 512K card tonight at the 48 Club meeting in
  33. L.A., and it has a BANKN function that allows you to bank switch WITHOUT
  34. PERFORMING A SYSTEM HALT.  The owner's manual clearly states that doing
  35. this while there are any memory references to objects in the bank being
  36. switched out will "at best cause unpredictable results."  The reason this
  37. is so is the same as the reason that FPGDIR is dangerous.  If Tripod can
  38. sell an item with functionality that's dangerous to use and assumes that
  39. the user takes proper precautions, then I hope I can give away FPGDIR for
  40. free with the same danger and assumptions.
  41.  
  42. What scares me, however, is the second moral.  People are hiding things
  43. gleefully, without any idea that Memory Clear awaits them if they don't
  44. know the pitfalls of PURGE on directories whose contents are all hidden.
  45.  
  46. EduCALC Goodies Disk #5 will, of course, have all this documented,
  47. hopefully to make up for the blissful endorsement of using null-named
  48. objects that has been on previous Goodies Disks.
  49.  
  50. Thanx, Bill, for warning us of the dangers here, before my "wonderful new
  51. discovery" (*sigh*) proliferated too far.
  52.  
  53. -- a crestfallen jkh --
  54.  
  55. From comp.sys.handhelds Sun Jun  9 13:52:04 1991
  56. Path: seq!ecsgate!mcnc!gatech!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpcvra.cv.hp.com!rnews!hpcvbbs!akcs.joehorn
  57. From: akcs.joehorn@hpcvbbs.UUCP (Joseph K. Horn)
  58. Newsgroups: comp.sys.handhelds
  59. Subject: HP 48 Faster PGDIR
  60. Message-ID: <284dca48:3374comp.sys.handhelds@hpcvbbs.UUCP>
  61. Date: 6 Jun 91 05:40:08 GMT
  62. Lines: 85
  63.  
  64. FPGDIR, a FAST PGDIR, by Joseph K Horn.  Makes PGDIR obsolete.
  65.  
  66. When you use PGDIR on a very large directory, it can take a long time
  67. to finish.  For example, I just used Donnelly's XTIME function to time
  68. PGDIR on a big directory, and it took a painful 50 seconds!
  69.  
  70. Bill Wickes explains why in his excellent book, "HP 48 Insights":
  71.  
  72.      "PGDIR removes a directory specified by name.  It does
  73.       this by recursively executing CLVAR and PURGE recursively
  74.       on each subdirectory until the original directory is
  75.       empty.  (This process can take a relatively long time if
  76.       the directory is large.)"  [Part I, page 96]
  77.  
  78. Guess what!  There's a better way!
  79.  
  80. Those of you with HP-41CX's will remember the CLRALMS command that
  81. cleared all the alarms out.  If you had a lot of alarms, it took a
  82. long time to finish, because it looped through the alarm buffer
  83. clearing each one individually.  But a much better way was to treat
  84. the entire buffer as one object, and clear it in one fell swoop.
  85. This was possible with the buffer clearing functions available in
  86. several plug-in ROMs.  For example, with the Extended-IL ROM, just
  87. execute 10 CLRBUF, and instantly the entire alarm buffer gets
  88. cleared, no matter how large it is.
  89.  
  90. It turns out that there is a similar trick for purging directories
  91. on the HP 48.  Rather than painfully looping through them, clearing
  92. their contents, we can treat the whole thing as a single object and
  93. PURGE it in one fell swoop.
  94.  
  95. Here's the trick.  The HP 48 Owner's Manual says:
  96.  
  97.      "Once a directory is empty, you can purge it like any
  98.       other variable -- put its name on the stack and execute
  99.       PURGE."  [Volume 1, page 123]
  100.  
  101. But "empty" means "when VARS == { }".  And VARS == { } when all
  102. the vars are "hidden" behind a null-named object (see NULLNAME.DOC
  103. on Goodies Disk #1).
  104.  
  105. So the quick way to purge a directory is:
  106.  
  107. (1) Put its name on the stack;
  108. (2) Get into that directory: DUP EVAL;
  109. (3) Unhide everything (just in case): '' PURGE;
  110. (4) Hide all its vars: 0 '' STO;
  111. (5) Go back to the parent directory: UPDIR;
  112. (6) Purge the "empty" directory: PURGE.
  113.  
  114. This process is automated by the following replacement for PGDIR:
  115.  
  116. ---------------------< FPGDIR >---------------------------------
  117. %%HP:T(1);
  118. \<<
  119.     IF DUP TYPE 6 ==
  120.     THEN
  121.       IF DUP VTYPE -1 ==
  122.       THEN DROP
  123.       ELSE
  124.         IF DUP VTYPE 15 ==
  125.         THEN DUP EVAL 0 # 15777h SYSEVAL DUP PURGE STO UPDIR PURGE
  126.         ELSE 515 DOERR
  127.         END
  128.       END
  129.     ELSE 514 DOERR
  130.     END
  131. \>>
  132. ----------------------------------------------------------------
  133.  
  134. Except for its improved speed, its action is exactly like PGDIR.
  135. It even generates the same error messages as PGDIR in case of bad
  136. arguments.  Nonexistent names simply get dropped (like PGDIR does).
  137.  
  138. To use: place name of directory on stack, and run it.
  139.  
  140. It does full argument type checking, so it should be idiot proof.
  141.  
  142. I keep it assigned to my blue-shifted DEL key.  That way it takes only
  143. three keystrokes to delete a directory (tic, menu, FPGDIR).
  144.  
  145. It should be in "system RPL" ... but that's left as an exercise for
  146. the reader.  :-)
  147.  
  148. --  Joseph K Horn  --  Peripheral Vision, Ltd.  --
  149.  
  150.